@chmerdon Seems fine now. I think the module is more maintainable if we have only a single Project.toml.
Adding new test dependencies can now easily be done in the [extras] section plus in the [targets] list.

... It is a matter of taste IMHO. I didn't find a reference stating what is preferred by the julia developers.

I personally kind of prefer to have test/Project.toml . Anyway we also have docs/Project.toml.

When I was new to Julia I was always confused by the splitting into test/main Project.toml. I think @chmerdon has to decide here :)

docs is different. For me, docs is an independent project on top of the actual module.

is docs really that independent? it runs the same examples, uses all the docstrings... I also find it weird to have then still the docs/Project.toml separately. Can one handle the docs similarly with another target docs?

Technically, docs is a project/environment on its own. You explicitly activate docs in order to create the docs.
Testing, on the other hand, is done out of the main project.

As far as I know, the only valid [targets] are test and build (see Julia Doc).

And I think 2 Project.toml files are still better than 3 separate files :)

Rebased to current master. Will merge if CI passes.

see this discussion on discourse: https://discourse.julialang.org/t/about-checking-a-package-library-manifest-toml-into-control-version-again/127490/8

From the discussion I take home that the current creation of the test environment is a mess if a separate test project is provided. I would really prefer to test in the environment of the project itself, sice we basically do full example testing here.
This is exactly what a downstream package would do. Create a script, add additional deps and run. This is what the [extras] do for us, right?

We seem to have some weird compat problems along the WIAS-PDELib. Let us keep things as simple as possible to track down these problems.
If a future development clears the relation to the main project and the test project, simply revert this change. It just takes a few minutes to set up a separate test environment again.

PS: Right now the CI fails since before the test environment was different than it is now. This pretty much underlines my argument.

... the currently failing test doesn't seem to fail due to CI configuration, but seems to assume that mesh generation always results in the same grid size, however due to floating point arithmetic this is true only approximately.

In VoronoiFVM you can look up how to test on Apple Silicon, I would add this here.

Yes, you are right. The CI fail occurred before on the master branch after merging the latest PRs. You think this is caused by floating point arithmetic problems? Why did the test work before?

As suggested by @chmerdon I deactivated Example211 for now. As a reminder I opened #44.